Organizations increasingly depend on critical applications and data in the course of business. Accordingly, an organization may wish to control the risk of losing any data managed by an application. For example, the application might run at a local computing site where a disaster could occur, destroying the application, its data, and any local backup mechanisms. The organization might ameliorate such a risk by replicating the data to a remote site (e.g., mirroring, at the remote site, the volumes on which the application and data reside).
Data replication may be synchronous, meaning that a change to the data at the local (or primary) site must first be committed to the remote (or secondary) site. Synchronous data replication may help to ensure that any data processed by the application will be recoverable. However, synchronous data replication may create latency in the application (i.e., the application may stall while the primary site waits for a change verification from the secondary site).
Because of the drawbacks of synchronous replication, an organization may employ an asynchronous replication system. Asynchronous replication may commit a change to the data at the primary site without first ensuring that the change is made to the secondary site. Consequently, some data processed by the application may not be recoverable (e.g., if the primary site is destroyed after a change to the data is committed to the primary site but before the change is fully transmitted to the secondary site).
In the course of planning and/or administrating a system for asynchronous replication, an organization may set standards for acceptable data loss in case of a disaster. One such standard may be a recovery point objective. The recovery point objective may set an acceptable level of data loss, measured in time (e.g., the length of time during which, in the case of a primary site disaster, changes will be committed to the primary site but will never successfully be made to the secondary site).
In order to assess the potential data loss in case of a disaster, a system may be equipped to perform a disaster recovery test. Some technologies may attempt to measure data loss during the disaster recovery test. For example, certain hardware-based replication systems may report the percentage of changed data for the primary site and the secondary site. However, the organization may prefer or require the potential data loss to be reported in terms of time. For instance, a service-level agreement may require a certain recovery point objective, which may only be expressed in terms of time.
An additional disadvantage of measuring data loss through certain hardware-based replication systems may be that a hardware-based replication system may report data loss relating to logical units (e.g., LUNS). Assessing the data loss corresponding to a particular application may still require mapping logical units to the application. Such a mapping may require specific consideration of the volume manager, operating system, and storage array in use. Furthermore, if the application runs on a virtual machine, the mapping may require specific consideration of the hypervisor managing the virtual machine.